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Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://webapp.etsi.org/IPR/home.asp ). 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 

This Technical Specification (TS) has been produced by ETSI Technical Committee Telecommunications and Internet 
converged Services and Protocols for Advanced Networking (TISPAN). 

The present document describes the Service and Capabilities Requirements of TISPAN NGN Release 1. 



Introduction 



The present document specifies the requirements that need to be fulfilled by NGN technical specifications to provide 
services in an NGN. 

The present document considers two service sets: IP Multimedia Services and PSTN/ISDN Emulation services. Each of 
these service sets has its own clause, which is further divided into clauses providing clear and precise requirements for 
each of these two service sets. Further clauses provide generic network requirements to support service deployment and 
interoperability. 

The present document provides generic requirements on networks from a services point of view. Specific details of 
individual services and capabilities are provided in other documents. 
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Scope 



The present document specifies network requirements in terms of service-related capabilities for TISPAN NGN. The 
present document places requirements for all TISPAN NGN Release 1 subsystems. 

The present document provides generic requirements for services and interoperability in TISPAN NGN in terms of the 
capabilities for a network or networks. 

Requirements on service-related subsystems provide sufficient detail for architecture, networking requirements and 
protocols to be specified. Requirements on service independent subsystems are contained within the service-related 
subsystem requirements. 

Specific service requirements may be contained in other documents, as identified in the present document, and by other 
documents referencing the present document. 

The present document does not define services, only capabilities and requirements. The present document does not 
place requirements on terminals or other customer-owned equipment. The present document specifies the 
service-related requirements that are used to determine the network architecture, requirements and control protocols 
for a network interface to a customer environment. 

NOTE: The present document uses the term "NGN" only in the context of TISPAN. 
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document. 

• References are either specific (identified by date of publication and/or edition number or version number) or 
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Referenced documents which are not found to be publicly available in the expected location might be found at 
http://docbox.etsi.org/Reference . 

[1] ETSI TR 180 000: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); NGN Terminology". 
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[3] ETSI TS 122 141 (V7.0.0): "Universal Mobile Telecommunications System (UMTS); Presence 
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Communication from Citizen to Authority". 

[5] ETSI TS 188 003: "Telecommunications and Internet Converged Services and Protocols for 

Advanced Networking (TISPAN); OSS requirements; OSS definition of requirements and 
priorities for further network management specifications for NGNOSS definition of requirements 
and priorities for further network management specifications for NGN". 

[6] IETF RFC 3966: "The tel URI for Telephone Numbers". 

[7] IETF RFC 3261: "SIP: Session Initiation Protocol". 

[8] ETSI TS 187 001: " Telecommunications and Internet Converged Services and Protocols for 

Advanced Networking (TISPAN); NGN SECurity (SEC); Requirements". 
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ETSI TS 122 115: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 
Telecommunications System (UMTS); Service aspects; Charging and billing (3GPP TS 22.1 15)". 

ETSI TS 122 228: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 
Telecommunications System (UMTS); Service requirements for the Internet Protocol (IP) 
multimedia core network subsystem (IMS); Stage 1 (3GPP TS 22.228 version 7.3.0 Release 7)". 



3.1 



Definitions and abbreviations 



Definitions 



For the purposes of the present document, the definitions given in TS 122 228 [10] and TR 180 000 [1] apply: 

• IP multimedia application (see TS 122 228 [10]); 

• IP multimedia service (see TS 122 228 [10]); 

• IP multimedia session: (see TS 122 228 [10]); 

• IP Multimedia Core Network Subsystem (IM CN Subsystem) (see TS 122 228 [10]); 

• nomadism (see TR 180 000 [1]); 

• portability (see TR 180 000 [1]). 



3.2 



Abbreviations 



For the purposes of the present document, the following abbreviations apply: 

ACR Anonymous Communications Rejection service requirements 

AMR Adaptive Multi-Rate 

AN Access Network 

CLIP Calling Line Identification Presentation 

CN Core Network 

CS Circuit Switched 

DSL Digital Subscriber Line 

ECN Electronic Communication Network 

IM IP Multimedia 

IMS IP Multimedia Subsystem 

IP Internet Protocol 

IPCAN IP-Connectivity Access Network 

IPv4 Internet Protocol version 4 

IPv6 Internet Protocol version 6 

ISDN Integrated Services Digital Network 

LI Lawful Interception 

MCID Malicious Communication Identity service requirements 

NAI Network Access Identifier 

NAT Network Address Translation 

NGN Next Generation Network 

PBX Private Branch eXchange 

PLMN Pubhc Land Mobile Network 

PSTN Public Switched Telephone Network 

QoS Quality of Service 

SLA Service Level Agreements 

UE User Equipment 

URI Uniform Resource Identifier 
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4 Capabilities for the support IP IVIultimedia Services 

This clause covers the requirements of the IP Muhimedia services supported by the NGN IMS. 



4.1 



Business models 



The NGN supports business agreements between the access network operator and the network operator providing NGN 

IMS services (NGN IMS operator). 

The NGN IMS shall be able to offer services to users that are attached to access networks owned by another operator. 

The service offering may be restricted by the capabilities of the access network and the business agreement between the 
access network operator and the NGN IMS operator. 

The NGN shall support at least the following operator's business domain relationships: 

a) Access network to IMS relationships 

a. 1) Access network and the NGN IMS network it connects to, belong to the same operator as shown in 
figure 1. 



lntra;^gerator 
Relationship a 




NGN 




Figure 1 

a.2) Access network and the NGN IMS network it connects to, belong to different operators having an 
interconnection agreement as shown in figure 2. 



Relationship b 




Access network 
Operator B 




NGN 




Figure 2 



b) IMS level relationships 



b.l) The IMS network (e.g. 3GPP or NGN) to which the access network connects and the Home IMS 

network (e.g. NGN or 3GPP) which provides the IMS services belong to different operators as shown in 
figure 3. 




Figure 3 
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b.2) The IMS network (e.g. 3GPP or NGN) to which the access network connects and the Home IMS 
network (e.g. NGN or 3GPP) which provides the IMS services are the same as shown in figure 4. 



Relationship d 




NGN 




Figure 4 

b.3) The IMS network (e.g. 3GPP or NGN) to which the access network connects and the Home IMS 

network (e.g. NGN or 3GPP) which provides the IMS services belong to the same operator as shown in 
figure 5. 




Figure 5 

A NGN IMS operator shall be capable of connecting to other network operators via: 

• an interconnect model where bi-lateral Service Level Agreements are established between two operators; 

• an interconnect model where intermediate network(s) can provide interconnect on behalf of multiple operators 
(and may be based on a single Service Level Agreement between the operators and their intermediate network 
provider). 

A single NGN IMS operator shall be able to choose to support either of the interconnect models, or both of the 
interconnect models simultaneously. 

4.2 Service requirements 
4.2.1 General services requirements 

The principle of access independence, as defined by the business models described above, shall be supported. 

It is desirable that an operator should be able to offer services to their subscribers regardless of how they obtain an IP 
connection through an access network as long as there is a business (roaming) agreement between access operator and 
IMS operator. 

IP multimedia sessions shall be able to support a variety of different media types. 

Within each IP multimedia session, one or more IP multimedia applications shall be supported. 

The network shall provide the capability for the user to invoke one or more IP multimedia sessions. Where more than 
one application is supported within a multimedia session by the network, the user may activate concurrent IP 
multimedia applications within each IP multimedia session. 

The network shall store information about the state (e.g. attached/non-attached) of a user's access connection, whether 
the user is roaming or not. According to policies this information may be provided to applications. 
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The network shall have the capability to hold user location information, whether the user is roaming or not. According 
to policies this information may be provided to applications. 

The network shall deliver additional information (e.g. Picture, Video, text), provided by the user, to the parties 
involved, during any phase of the communication. The additional information may not be related to any media flow. 

4.2.2 Handling of sessions 

4.2.2.1 Handling of session establishment 

4.2.2.1 .1 Presentation of session originator identity 

The network shall present the identity of the session originator (as in clause 4.4). The network shall suppress the 
presentation of the identity when requested by the session originator. 

NOTE: The requirements for support of emergency communications may over-ride the user request for 
suppression. 

4.2.2.1 .2 Negotiation of an incoming session 

Interaction with the user profile shall be supported, and additionally direct interaction with the user may be required. 
Refer to clause 4.2.2.4 for further details on capability negotiation on an incoming IP multimedia session. 

4.2.2.1 .3 Accepting or rejecting an incoming session 

The network shall support the capability for the user to accept, reject, ignore or re-direct an incoming IP multimedia 
session. 

4.2.2.2 Handling of an ongoing session 

4.2.2.2.1 User modification of media in an ongoing session 

The user shall be able to negotiate the addition or deletion of media components of IP multimedia applications during 
an IP multimedia session. Refer to clause 4.2.8 for further details on capability negotiation during an IP multimedia 
session. 

4.2.2.2.2 Presentation of identity of session terminator 

The network shall support the capability to present to the session originator the identity (as in clause 4.4) of the session 
terminator. The network shall suppress the presentation of the identity when requested by the session terminator. 

NOTE: The requirements for support of emergency communications may over-ride the user request for 
suppression. 

4.2.2.3 Handling end of session 

If there are one or two participants in the IP multimedia session, the network shall end an IP multimedia session at any 
time during the session, when requested by any of the IP multimedia session users. The network may end an IP 
multimedia session at any time during the session (e.g. in failure conditions). 

If there are more than two participants in the IP multimedia session the network may end an IP multimedia session at 
any time during the session, when requested by any of the IP multimedia session users. The network may end an IP 
multimedia session at any time during the session (e.g. in failure conditions). 
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4.2.2.4 Capability negotiation 



The network shall provide the capability for IP multimedia applications (whether it is an application of a user or the 
network) to negotiate their capabilities by identifying and selecting the available media components, QoS etc. of IP 
multimedia sessions. The network shall support the capability for negotiation to take place on invocation, acceptance 
and during an ongoing IP multimedia session (e.g. following a change in UE capabilities, change in media types, etc.). 
The user, network, or an application on behalf of the user or network may initiate capability negotiation. 

In order to support user preferences for IP multimedia applications, the capability negotiation shall take into account the 
information in the user profile whenever applicable. This includes the capability to route the IP multimedia session to a 
specific UE, when multiple UEs share the same IMS service subscription. 

4.2.2.5 Redirecting of IP Multimedia sessions 

The network shall support the capability for the user, or the network on behalf of the user, to identify an alternative 
destination for an IP multimedia session or individual media of an IP multimedia session. The originating entity, 
terminating entity or the network on their behalf, may initiate redirection to alternative destinations. It shall be possible 
for redirection to be initiated at various stages of an IP Multimedia session. For example: 

• Prior to the initial request of an IP Multimedia session. 

• During the initial request for an IP Multimedia session. 

• During the establishment of an IP Multimedia session. 

• While the IP Multimedia session is ongoing. 

Redirection can be applied for all Multimedia sessions unconditionally or it can be caused by any of a set list of events 
or conditions. Typical causes could be: 

Identity of the originator. 

Location or presence of the originator or terminator. 

If the terminator is already in a session. 

If the terminator is unreachable or unavailable in some other way. 

If the terminator does not respond. 

After a specified alerting interval. 

User's preference on routing for specific IP Multimedia session based on the capabilities of multiple UEs 
sharing the same IMS service subscription. 

Time of day. 

4.2.2.6 User busy 

4.2.2.6.1 User determined user busy 

The network shall support the capability of a user to reject an incoming IP multimedia session with an indication of 
"user busy". This indication may be used by the network as a trigger for certain services e.g. Call Forwarding on Busy. 
If the session rejection is propagated back to the originator, the "user busy" indication must be provided as the cause of 
the rejection. 
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The conditions for user determined "user busy" include: 

• the session is offered to a single contact that rejects with a "user busy" indication; or 

• the session is offered to multiple contacts with a single public identity, and one contact rejects with a "user 
busy" indication on behalf of the set of contacts; or 

• the session is offered to multiple contacts; and 

none of the contacts progress the session; and 

one or more of the contacts rejects with a "user busy" indication. 

4.2.2.6.2 Network determined user busy 

The capability of network determined user busy is a network option. 

The network may determine busy conditions at the time an incoming IP multimedia session is about to be offered. 

The conditions for network determined user busy are identified, on a per subscription basis, based on the availability of 
limited resources assigned to the terminating user, or due to other information such as presence. 

The conditions for network determined "user busy" include: 

• the maximum number of total communications permitted has been reached; 

• the maximum number of simultaneous media streams supported at the given subscriber's interface(s) has been 
reached; 

• the maximum bandwidth supported at the given subscriber's interface(s) has been reached. 

The network determined user busy condition may be used to trigger certain services (e.g. Call Forwarding on Busy), or 
reject the session, or both. If the session rejection is propagated back to the originator, a "user busy" indication must be 
provided as the cause of the rejection. 

In addition, a further condition, "approaching network determined user busy" that is related to the Network determined 
user busy condition, may be provided. This condition may be used to trigger certain services. However, this condition is 
not a busy condition and shall not cause a "user busy" indication being sent towards the session originator. 

The conditions for approaching network determined user busy are identified, on a per subscription basis, based on the 
availability of limited resources assigned to the terminating user. 

The conditions for approaching network determined user busy include: 

• a pre-determined number, or less, of communications are available (i.e. the maximum number of 
communications minus the current number); or 

• a pre-determined number, or less, of simultaneous media streams available (i.e. the maximum number of 
simultaneous media streams minus the current number); or 

• a certain limit in the bandwidth used at the given subscriber's interface(s) has been reached. 

4.2.3 PSTN/ISDN Simulation Service 

The NGN shall provide the capability for a service operator to simulate one or more PSTN/ISDN services. PSTN/ISDN 
simulation that provides the user with an experience that may or may not differ to an existing PSTN/ISDN experience. 
The way in which PSTN/ISDN services are delivered shall not impact on the delivery of new NGN services. 

The specific requirements for the PSTN/ISDN simulation service are described in TS 181 002 (see Bibliography). 

4.2.4 IMS messaging 

The capabilities to support immediate messaging and session based messaging shall be as described in TS 122 340 [2]. 
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4.2.5 Presence Service 

The capabilities to support Presence Service shall be as described in TS 122 141 [3]. 

4.2.6 Location Service 

The NGN location service shall provide a mechanism that may offer network asserted location information to 
applications. The provision of location information to applications shall depend on policies and user preferences. 

The network asserted location mechanism shall identify the physical access through which user connectivity is granted. 

The network asserted location mechanism shall locate individual users that have authenticated with the access network. 

The NGN access network shall provide location information to the IMS . Location information provided by the NGN 
access network to the IMS shall include network asserted location information. 

The actual location information may take various forms (e.g. network location, geographical coordinates, post mail 
address, etc.), depending on agreements between the access and IMS providers and on user preferences regarding the 
requested privacy of their location. 

4.2.7 VideoTeleplnony Service 

The capabilities to support a video telephony service are described in TS 181 001 (see Bibliography). 

4.3 Mobility 

The NGN shall support terminal portability as defined in TR 180 000 [1]. 

The NGN shall support nomadism, as defined in TR 180 000 [1], and described below. 

The NGN shall support the capability for a user to change to a different device or devices connected to one or more 
access networks to gain access to their services. 

The NGN shall support the capability of the user to change network access point whilst moving. 

Note: where the access network technologies are identical and owned by the same access network operator, session 
continuity or handover shall be supported if the technology allows. Where session continuity or handover is not 
supported, the user's service session is completely stopped. 

NOTE: Where the access network technologies are not identical, session continuity or handover need not be 
supported. 

The NGN home network and visited network shall support the capability of providing services from the NGN home 
network to a user connected to the visited network. This is shown by diagram under b.l) within clause 4.1 (Business 
Models). 

Services should be able to be reconfigured so as to be suitable for the target network and target device. The service shall 
be reconfigured at the time the user first accesses the service from a new location. 

For particular services, mobility shall not interfere with the provision of all information required by the service 
(e.g. geographic location information). 

4.4 Number, naming and addressing 

The NGN shall provide the capability to uniquely identify each user. This Identity Information shall include at least the 
asserted public identity. This identity information is verified. 

Both telecom and Internet numbering and addressing schemes shall be supported as public identities. IP multimedia 
communication establishment (both originating and terminating) depending on originator shall be able to be based on 
E.164/tel URI (see RFC 3966 [6]) or SIP URI (see RFC 3261 [7]). It shall be possible to assign several public identities 
for one subscription. 
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NOTE: Numbering and addressing schemes other than E.164/tel URI or SIP URI are not precluded from later 
releases. 

Public identities shall be administered by the network operator and shall not be changeable by the user. 

The network operator shall guarantee the authenticity of a public identity presented for an incoming session to a user 
where the communication is wholly across trusted network. This is equivalent to the situation for CLIP with today's 
telephony networks. 

The NGN IMS is not required to support the generation of overlap signalling. Interworking Requirements (as in 
clause 4.9) require options for conversion. 



4.5 Terminal requirements 



The present document does not specify terminal requirements. However, NGN terminals (not precluding network 
adaptors) that comply with the NGN IMS UNI interface offered by the network, shall be supported by the NGN. 

The NGN IMS UNI interface is not required to support 3GPP mobile terminals in Release 1 . 

It is a service provider option to support a 3GPP IPCAN for a user to access the NGN IMS. The NGN IMS shall 
support 3GPP mobile terminals connected via the 3GPP IPCAN. 

Terminal developers guidelines are provided in annex B. 

4.6 Regulatory service requirements 

4.6.1 Lawful Intercept 

The capabilities to support Lawful Intercept shall be as described in TS 187 005 (see Bibliography). 

4.6.2 Emergency service 

The capabilities to support the Emergency Service shall be as described in TS 102 424 [4]. 

4.6.3 Identifying malicious communications 

The NGN shall support the capability for a user to identify a communication as malicious. This service may be 
available to a user only after subscription. Once the user has indicated to the network that the communication is 
malicious, the NGN IMS shall register at least the following information: 

• Terminating Identity Information; 

• Originator Identity Information; 

• Local Time and Date of the invocation in the network serving the terminating entity; 

The information shall not be available to the terminating entity nor the originating entity. The information shall be 
under the control of the network operator. 

The user may identify the communication as malicious during the alerting phase, during an ongoing communication, or 
for a limited period after the communication has ceased. 

4.6.4 Anonymous communications rejection 

A session is considered anonymous when a user receiving an incoming session cannot identify the originator. 

Anonymous communications rejection provides the capability for network, on behalf of the user, to reject incoming 
sessions from users who have restricted the presentation of their originating identity. 
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The NGN IMS shall support the capability to be able to reject all terminating sessions when the originating entity 
cannot be identified, i.e. the asserted originating identity is marked "presentation restricted" or "presentation restricted 
by network" . 

4.7 Access network requirements 

Any access to the NGN core shall provide IP connectivity, i.e. allow transport of IP packets between end user 
equipment and the NGN core. 

Solutions for access to the NGN core shall support the assignment of IP addresses to the end user equipment by the 
access network. These addresses may not be routable in the public Internet. 

Solutions for access to the NGN core shall not require changes to existing access technology infrastructure. All 
solutions for access to the NGN core shall support the presence of NAT and firewalls in the access network 
environment. Impacts on access networks shall be minimized. 

An NGN deployment shall not inhibit user access to the Internet and other IP networks through existing mechanisms, 
e.g. ISP offering of internet access to DSL users. 

4.8 Customer Networks 

4.8.1 General 

Access from a customer network to the NGN core shall provide IP connectivity, i.e. allow for transport of IP packets 
from the end user equipment. 

Solutions for access from a customer network to the NGN shall be able to cope with the assignment of IP addresses to 
the end user equipment by the customer network. These addresses may not be routable in the public Internet. 

Solutions for access from a customer network to the NGN shall not require technological changes to existing customer 
network technologies. 

Solutions for access from a customer network to the NGN shall have minimal impact on existing customer network 
deployments. 

4.8.2 Home and Small Office Networks 

Solutions for access from a Home and Small Office network to the NGN shall be able to cope with NAT and firewalls 
in the home/small office environment. 

Solutions for access from a Home and Small Office network to the NGN shall support the following configurations: 

• Direct connectivity and interaction between the individual terminals and the NGN. 

• Indirect connectivity and interaction between the individual terminals and the NGN (e.g. via IP PBXs). 

4.8.3 Corporate Networks 

Solutions for access from a corporate network to the NGN shall be able to cope with NAT and firewalls in the corporate 
environment. 

Solutions for access from a Corporate network to the NGN shall support the following configurations: 



• 



Direct connectivity and interaction between the individual terminals and the NGN (e.g. to support Ipcentrex 
configurations). 

Indirect connectivity and interaction between the individual terminals and the NGN (e.g. via IP PBXs). 
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4.9 Interworking 

4.9.1 Interworking with Legacy PSTN/ISDN 

The NGN IMS shall support interworking with the legacy PSTN/ISDN network. 

The NGN IMS interworking with the legacy PSTN/ISDN network shall not impact the NGN IMS subsystem or the 
PSTN/ISDN network. The NGN IMS network shall support the capability for limited interoperability with an existing 
PSDN/ISDN. 

The NGN IMS shall support the interoperability of PSTN/ISDN like services with PSTN/ISDN Supplementary Services 
and vice versa. The scope of this interworking may result in a limited service capability. 

4.9.1 .1 Overlap Signalling 

Support for overlap signalling in the NGN IMS is as an operator option limited to the interworking with legacy 
PSTN/ISDN networks that use overlap signalling. 

NGN Networks that interconnect to legacy PSTN/ISDN networks that do not implement overlap signalling are not 
required to support the feature. 

For these requirements, PSTN/ISDN networks that convert overlap signalling (received from other PSTN/ISDN 
networks) to en-bloc, are considered to be a network that does not support overlap signalling. 

The NGN IMS shall interoperate to legacy PSTN/ISDN networks that supply overlap signalling. The following 
requirements shall be taken into account: 

• Conversion of overlap signalling to en-bloc shall take place within the NGN domain (without change to the 
legacy PSTN/ISDN). 

• Impact on the IMS shall be minimized. 

• A network option shall be provided to enable conversion to be performed using either: 

a simple solution (digit counting, simple look-up, or end-of-digit timer, etc.); 

complete solution - which shall minimize the post-dialling delay (may require an iterative look-up 
solution). 

NOTE: Overlap signalling support should not be linked to E. 164 numbering schemes. 

The NGN IMS is not required to support the generation of overlap signalling. 

The NGN IMS is not required to support overlap signalling from terminals and customer networks. 

4.9.2 Interworking with PSTN/ISDN Emulation 

The NGN IMS shall support interworking with the PSTN/ISDN Emulation subsystem. 

The NGN IMS shall support the capability for limited interoperability with an emulation subsystem. 

The NGN IMS shall provide at least the same level of interoperability with an emulation subsystem as achieved with 
legacy PSTN/ISDN networks. 

Support for overlap signalling between the IMS and PSTN/ISDN Emulation is dependent on the network options for 
conversion. 
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4.9.3 Interworking with PLMN 

4.9.3.1 Interworking with IIVIS based PLIVIN 

The NGN IMS shall interwork with an IMS based PLMN without impacting either the NGN IMS or the IMS-based 
PLMN. 

4.9.3.2 Interworking with PLIVIN - CS Domain 

The NGN IMS networks shall provide interfaces to PLMN - CS Domain networks. 

The NGN IMS shall support interworking with the PLMN - CS Domain network. 

The NGN IMS interworking with the legacy PLMN - CS Domain network shall not impact the NGN IMS subsystem or 
the PLMN - CS Domain network. The NGN IMS network shall support the capability for limited interoperability with 
an existing PLMN - CS Domain. 

The NGN IMS shall support the interoperability of PSTN/ISDN like services with PSTN/ISDN Supplementary Services 
and vice versa. The scope of this interworking may result in a limited service capability. 

4.9.4 Interworking witin Packet Cable network 

The NGN IMS shall support interworking with Packet Cable networks. 

The NGN IMS interworking with the Packet Cable network shall not impact the NGN IMS subsystem or the Packet 
Cable network. The NGN IMS network shall support the capability for limited interoperability with an existing Packet 
Cable Network. 

4.9.5 Interworking witin otiner NGN IMS network 

A TISPAN -compliant NGN IMS shall interwork with other NGN IMS based networks without impacting the TISPAN 
NGN IMS. 

4.9.6 Interworking witin otiner networks 

The NGN IMS shall support interworking with non-IMS and non-TDM multimedia networks. The interworking with 
non-IMS and non-TDM multimedia networks shall not impact the NGN IMS. 

4. 1 Quality of Service (QoS) 

The NGN shall support the following: 

A wide range of QoS -enabled services. 

Dynamic negotiation of QoS parameters between service and access providers based on an SLA. 

Terminals that are not capable to indicate QoS requirements as part of the service request. Terminals that are 
capable shall also be supported. 

QoS provisioning within the access segment. QoS in the core transport network is considered to be achieved 
by other means that are out of the scope of NGN Release 1 (e.g. Overprovision). 

The provisioning of QoS for application traffic where upstream and downstream flows have specific QoS 
requirements. 

An architecture that supports bandwidth reservation. 

QoS mechanisms to allow efficient use of access resource. 
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4.1 1 Security Requirements 

4.11.1 General 

The NGN shall provide sufficient security services and mechanisms to meet the service requirements given in the 
proceeding clauses. The security threat & risk analysis gives the rationale for quahfying what is to be understood as 
"sufficient security". 

The NGN IMS subsystem shall provide services, including connectivity, to a user entitled to use the resources of the 
NGN and the IMS subsystem. 

The Access Network shall provide access connectivity to a user entitled to use the resources of the Access Network. 

The NGN shall support independent verification by IMS and Access Network of the previous two requirements. 

However, to facilitate the early deployment of NGN, two special legacy scenarios, permit the verification to be linked. 
These two special deployment scenarios are: 

A) IMS authentication is linked to access line authentication (no nomadism). 

B) IMS authentication is linked to access authentication for IP Connectivity (limited nomadism can be provided). 
Both scenarios A and B shall allow UEs to perform access independent authentication to the IMS. 

4.11.2 NGN Security 

Detailed Security Requirements shall be as contained in TS 187 001 [8]. 

4.1 1 .3 Network Domain Security 

The detailed requirements for network domain security are contained in TS 187 001 [8]. 



4.12 Ciiarging and Accounting 



Charging and accounting in NGN will be based on the collection of information from appropriate entities in the form of 
Charging Data Records (CDRs). The requirements for charging and accounting shall be as contained in 
TS 122 115 [9]. 



5 PSTN/ISDN Emulation Service 

5.1 Business IVIodels 

The business model envisaged for PSTN/ISDN Emulation Service is the replacement (in whole or part) of an existing 
PSTN/ISDN network based on TDM with an Emulation based on IP technology. An alternative business model is the 
provision of PSTN/ISDN service over connections derived from broadband service, which compete with the existing or 
Emulated PSTN. Both business models may co-exist in the same market place. 

A NGN service provider shall be capable of connecting to other service provider via: 

• an interconnect model where bi-lateral Service Level Agreements are established between two service 
providers; 

• an interconnect model where intermediate network(s) can provide interconnect on behalf of multiple service 
providers (and may be based on a single Service Level Agreement between the SP and their intermediate 
service provider). 

A single NGN service provider shall be able to choose to support either of the interconnect models, or both of the 
interconnect models simultaneously. 
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5.2 Service Requirements 



The NGN shall support PSTN /ISDN emulation that provides the user with an identical experience to that of the 
existing PSTN/ISDN. 

The NGN shall support the ability for a service operator to emulate one or more of their PSTN/ISDN services. 

The NGN shall support service capability definitions inherited from existing PSTN/ISDN specification. The service 
descriptions of the existing services for any particular network are outside the scope of the present document. 

It is an objective that the user shall be unaware of a change from legacy PSTN/ISDN to PSTN/ISDN emulation for 
those services that are emulated. For each emulated service, the service capability definitions are inherited from existing 
PSTN/ISDN specifications. Specific service requirements related to PSTN/ISDN Emulation are described in the 
following clauses. 



5.3 IVIobility 



There is no requirement to support mobility or a nomadic capability for PSTN/ISDN Emulation. There are no 
additional mobility requirements. 

This does not prevent the existence of user nomadism where it is implicit in the chosen business model nor does it 
require that nomadism be actively prevented. 

5.4 Number, naming and addressing 

The users of PSTN/ISDN Emulation will be allocated numbers (or number ranges) in the appropriate E. 164 number 
space allocated by the national numbering authority. The nature of this E.164 number will vary from operator to 
operator and from country to country. The design shall permit the use of both geographical and non-geographical E.164 
numbers. 

There is no requirement to support the use of non-E. 164 names within PSTN/ISDN Emulation but the use of non-E. 164 
names is not precluded. 

PSTN/ISDN emulation places no new requirements to support number portability. 

5.5 Terminal requirements 

The NGN shall support terminals that use existing PSTN/ISDN interfaces. 

Whilst the NGN has no role in standardizing terminals it is recognized that a key aspect of the PSTN/ISDN emulation 
subsystem is the ability to enable PSTN/ISDN replacement whilst maintaining all the existing services in the network. 

NOTE: More advanced terminals may use the PSTN/ISDN emulation subsystem to provide identical PSTN/ISDN 
services to the user. Such advanced terminals may or may not be able to access additional services not 
related to PSTN/ISDN emulation but the functions of such terminals are not subject to standardization 
within the Release 1 of NGN. 

5.6 Regulatory service requirements 
5.6.1 Lawful Intercept service requirements 

All implementations of PSTN/ISDN Emulation shall provide the ability to provide Lawful Interception in accordance 
with national requirements. Where possible the packet interception handover interfaces should be made available to 
authorities to avoid the ability of targets to maintain covert channels not monitored by TDM handover interfaces. Packet 
handover is most important for derived service where the packet stream is not under direct control of the provider of the 
Electronic Communication Network. 

The capabilities to support Lawful Intercept for Emulation shall be as described in TS 187 005 (see Bibliography). 
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5.6.2 Emergency service requirements 

The capabilities to support the Emergency Service shall be as described in TS 102 424 [4]. 

5.6.3 Malicious Communication Identity service requirements (MCID) 

MCID is a service which is expected to be provided in the context of the European Telecoms Privacy Directive or 
equivalent regulations in other jurisdictions. The service is required for all speech calls irrespective of which network 
originated the call. It is normally provided following a request from the customer concerned and may be subject to 
authorization. 

5.6.4 Anonymous Communications Rejection service requirements (ACR) 

The service capability definition for this service is inherited from existing PSTN/ISDN specifications and no new 
requirements are identified. 

5.7 Access Networks 
5.7.1 Wireline Access 

The deployment of an NGN supporting PSTN/ISDN emulation may support existing access methods and access 
network technologies. The PSTN/ISDN User-Network Interface shall not be affected. 

5.8 Customer Networks 

5.8.1 Home and Small Office Networks 

In the case of PSTN/ISDN Emulation used to replace an existing analogue or TDM network these are handled in the 
same way as the network which is being replaced or substituted. 

Where the business model involves derived voice the customer will present lines to either an Access Gateway or a 
Residential Gateway as appropriate. In some cases there will be a terminal that offers service in an alternative manner 
but that is not within the scope of the present document. 

A Residential Gateway may be situated within a Customer Access Gateway or on the customer network side of it. The 
Customer Access Gateway may use any suitable access technology. 

In addition where existing Primary Rate ISDN or equivalent services are provided the PSTN/ISDN Emulation may 
support them. The actual signalling systems and methods of presentation supported are a national matter, supported by 
the list of designated standards published by the European Commission. 

5.8.2 Corporate Networks 

Within the context of the PSTN/ISDN Emulation Corporate Networks may continue to be supported. The actual 
signalling systems and methods of presentation supported are a national matter supported by the list of designated 
standards published by the European Commission. This support may extend to the provision of VPN services using 
signalling systems and methods of presentation which are provided on a national basis and those that rely on European 
Standards. 
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5.9 Interworking 

5.9.1 Interworking with Legacy PSTN/ISDN 

PSTN/ISDN emulation shall provide interfaces to PSTN/ISDN networks. 

The NGN shall support the ability for the interconnection between two PSTN/ISDN and/or emulation networks to 
remain unchanged from the legacy case. 

PSTN/ISDN Emulation shall provide a high level of interoperability with the services in the PSTN/ISDN being 
emulated. The degree to which service interoperability is provided is a matter for operators of Public Electronic 
Communications Networks and, in some cases, national regulators. 

5.9.2 Interworking with PSTN/ISDN Emulation 

PSTN/ISDN Emulation shall provide a high level of interoperability with the services in other Emulated PSTN/ISDN 
networks. The degree to which service interoperability is provided is a matter for operators of Public Electronic 
Communications Networks and, in some cases, national regulators. 

5.9.3 Interworking with PLMN 

5.9.3.1 Interworking with IMS based PLMN 

Inter-working with the part of a PLMN that is based on an IMS shall be as described for inter-working with a NGN IMS 
network. 

5.9.3.2 Interworking with PLMN - CS Domain 

Inter- working with the circuit switched part of a PLMN shall be as described above for Inter- working with a 
PSTN/ISDN network. 

5.9.4 Interworking with Packet Cable Network 

Inter-working with the Packet Cable network shall be as described for Inter-working with a legacy PSTN/ISDN 
network or as described for Inter-working with an emulated PSTN/ISDN network. 

The choice of method is at the discretion of the operators concerned or as directed by a regulatory authority. 

5.9.5 Interworking with NGN IMS network 

Refer to clause 4.9.2. 

5.9.6 Interworking with other networks 

Inter-working with non-IMS and non-TDM network is the same as for inter-working with: 

i) A TDM based PSTN/ISDN as described above; or 

ii) Another PSTN/ISDN Emulation as described above. 
The choice of method is at the discretion of the operators concerned or as directed by a regulatory authority. 



5.10 Quality of Service (QoS) 



The PSTN/ISDN Emulation shall provide QoS transmission facilities to enable the same end-to-end performance 
requirements of the PSTN to be met. This includes any reservation of bit rate through the Access transport and also 
includes any transcoding facilities that may be needed. 
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5.1 1 Security requirements 



A PSTN/ISDN Emulation shall meet the security requirements placed on a national PSTN/ISDN network. Where 
appropriate, requirements and mechanisms may vary to take account of the underlying NGN and IP technology. 

5.12 Charging and accounting 

The requirements and mechanisms for charging are a national matter. 

6 Codecs services 

The following requirements apply to audio and video codecs support within the network. 

6.1 General 

It is the responsibility of entities at the rim of the NGN (e.g. NGN-TE) and Network equipment originating and 
terminating the NGN IP media flows, to negotiate and select a common codec for each "end-to-end" media session. 
Therefore the NGN shall allow end-to-end negotiation of any codec between NGN entities (terminal, network 
elements). 

6.2 Audio Codec 

In order to enable interworking between the NGN and other networks (including the PSTN, mobile networks and other 
NGNs) the NGN must be capable of receiving and presenting G.71 1 coded speech when interconnected with another 
network. When a packetization size is not selected by codec negotiation between terminals and/or network elements or 
agreed by bilateral arrangement, a speech packetization size of 10 ms samples should be used for G.711 coded speech; 
this is recommended as an optimum value balancing end-to-end delay with network utilization. It is recognized that 
there may be network constraints which require that a higher value is agreed by bilateral arrangement; in such cases a 
value of 20 ms is recommended. 

NOTE 1 : Where a packetization size is selected by codec negotiation between terminals and/or network elements 
the present document places no requirements on the value to be selected. 

NOTE 2: The above does not put any requirement about the codecs to be supported by terminals nor does it 
mandate that NGN networks shall support audio transcoding between any arbitrary codec to G.711. 

In addition, support for the following audio codecs is recommended: 

AMR: in order to support 3GPP terminals and to facilitate the interwork with 3GPP network. 

G.729A: in order to facilitate the interwork with existing VoIP networks and support existing VoIP terminals. 

In order to provide voice service with a superior quality experience by the end-user it is recommended to provide also a 
Wide-band codec. 

Audio transcoding may be performed to provide end-to-end service interoperability, but should be avoided wherever 
possible. 

6.3 Video Codec 

In order to enable the interworking for video communication services between an NGN Network and other Networks 
the support of the H.263 profile and H.264 baseline profile codecs is recommended. 

NOTE: The above does not put any requirement about the codecs to be supported by terminals nor does it 

mandate that NGN networks shall support video transcoding between any arbitrary codec and H.263 or 
H.264. 
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7 Network Attachment Requirements 

The user network profile contains user access authentication data and information related to the required network access 
configuration. 

The NGN shall support the re-configuration of services available to the user when the user is nomadic and accesses 
their services from a location other than the subscribed-to location. Services may be dependent on any or all of: the user 
device, the access network and arrangements (e.g. roaming agreements) between the Application provider and the 
access network provider. The access network shall allocate resources in accordance to the services to be provided. 

In access roaming scenarios, those access networks that provide access to NGN services shall be able to 
authenticate/authorize access to the network based on information retrieved from the access networks where the user is 
subscribed to. 

To guarantee the interoperability of roaming services, the NGN access network attachment procedures shall support 
access network authentication based on a standardized method for identifying users at access network level (e.g. the 
NAI mechanism specified in RFC 2486 (see Bibliography)). 

NAT based user authentication shall be supported. 



8 CPE Configuration 



The NGN shall be able to provide configuration parameters and obtain operational status of the CPE. This includes the 
ability to provide SW upgrade, service configuration, collect operational status. 



9 Network IVIanagement 

Network Management requirements shall be as described in TS 188 003 [5]. 

10 Control of Processing Overload 

The NGN shall have mechanisms available to control overload that: 

1) automatically maximize effective throughput (i.e. admitted service requests/sec) at an overloaded resource. 

2) achieve this throughout the duration of an overload event, and irrespective of the overloaded resource's 
capacity or of the number of sources of overload; 

3) are configurable by the service provider so that, under processing overload, a high proportion of response 
times at overloaded resources are low enough so as not to cause customers to prematurely abandon service 
requests; 

4) should be possible to be applied within a service provider's NGN, and between different service providers' 
NGNs; 

5) should be possible to be applied within an NGN subsystem (e.g. IMS, PSTN/ISDN emulation) and between 
different NGN subsystems. 

NOTE: As a general rule, an NGN's call, session and command processing resources can experience prolonged 
processing overload under the appropriate circumstances (e.g. partial, or full, server failure, high rates of 
incoming service requests). Consequently, it needs to be equipped with some form of overload detection 
and control (including expansive controls such as load balancing and resource replication), in order to 
keep response times just low enough under such processing overload to preclude customers abandoning 
their service requests prematurely. 
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11 IP Addressing 



The Operator of an NGN infrastructure may base the implementation on IPv4 only, IPv6 only or both. The choice is an 
operator option. 

NOTE 1 : It should be recognized that a mixture of IPv4 and IPv6 within a single operator domain can cause 
problems for service delivery. 

NGN operators may support customer equipment using IPv4 only, IPv6 only or both at an IP-based User-Network 
Interface. The choice is an operator option. 

NOTE 2: It is assumed that IPv6 based customer equipment can also support IPv4 at the User-Network Interface. 
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Annex A (informative): 

Basic communication cases for IIVIS networks 

A basic communication case can be described on a per IMS domain basis by stating the IMS domain entry point and an 
exit point for the communication as shown in figure 6. 

The following general types of entry /exit point can be identified for NGN Rl : 

• Access (for communication to from NGN terminals); 

• Interconnect to non-IMS network; 

• Interconnect to other IMS domain; 

• Internal network resource (e.g. a conference bridge for conferencing services). 

As a general rule a NGN shall support the following basic communication cases on a per NGN network basis. 

Table A.I 



From 
(entry point) 


To (exit point) 


Access Network 


Interconnect to other 
IMS domain 1 


Interconnect to 
non-IMS network 


Internal Network 
Resource 


Access Network 


Required 


Required 


Required 


Required 


Interconnect to other 
IMS domain 1 


Required 






Required 


Interconnect to 
non-IMS network 


Required 




Required 


Required 


Internal Network 
Resource 


Required 









NOTE 1: A basic communication case having an "interconnect to other IMS domain" as exit point need to be 

concatenated with another basic communication case having an "Interconnect to other IMS domain" as 
entry point to provide an IMS end-to-end communication. 

It is not precluded that other, more complex communication cases may be provided by service level concatenation of 
basic communication cases, e.g. by means of call diversion services. 

NOTE 2: The case of interconnection of non-IMS networks via the IMS network may be provided in Release 1 
depending on capabilities provided by WG2 and WG3. This interconnection is offered in a transparent 
way meaning that no further service (e.g. clearing house) is expected to be offered by the IMS network. 
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Figure A.I : Graphical representation of supported basic communication cases 
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Annex B (informative): 

Guidance for terminal implementation 

For a terminal to attach to the TISPAN NGN IMS Subsystem it should be capable of using an ISIM to authenticate to 
the NGN IMS. 

However, this does not preclude the use of non-ISIM capable terminals, if access using an ISIM application in another 
device is supported. Authentication based on line authentication (as in clause 4. 11) if applicable to the access is also 
supported. 

Software upgrades may be required e.g. for security purposes, as well as minor HW upgrades, e.g. chip card reader. 

Solutions for access to the NGN core shall support existing terminals (e.g. personal computers). The client software 
should be deployable making use of download techniques but should not impact the current operating system. 
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